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Abstract 

Theie  have  been  numerous  ideas  and  innovations 
deagned  to  enhance  the  affodability  of  Ballistic  Missile 
Defense  (BMD)  syst^s  developed  in  recent  years.  These 
innovations  inclu^inoeased  use  of  {xototype  hardware  in 
the  early  stages  of  system  develqxnent  to  gain  user 
feedback,  perform  early  evaluations  and  to  provide 
contingency  dq>loyment  options.  A  second  innovation  is 
the  formulation  of  capabilities  to  link  various  modular 
types  of  system  simulations  and  environmental  models 
together  to  create  virtual  worlds  in  which  these  highly 
interactive  systems  can  operate.  An  interesting  ippoach 
having  great  potential  for  yielding  more  affcxxlable  BMD 
systems  combines  these  two  tpproaches. 

The  marriage  of  Hardware-hi-’nie-Loop  (HWIL) 
with  distributed  simulation  technologies  allows  BMD 
devdopos  to  design  and  test  multiple  concepts,  improve 
existing  capabilities  and  evaluate  combinations  of 
systems.  In  additirxi,  this  tpfHoach  tests  the  system 
against  a  wider  range  rtf  threats  and  oivironmental 
conditions  at  a  h>w^  cost  than  traditional  methods.  The 
end-products  of  employing  Distributed  Hardwaie-lh-The- 
Loop  (D-HWIL)  technologies  are  lower  developmental 
cost,  fewer  problems  during  operational  testing,  greater 
opportunity  fcv  reuse  across  all  major  Defense  Acquisition 
Programs,  and  available  rapid  deployment  options. 

These  D-HWIL  capabilities  provide  a  more  robust 
test  environment  that  includes  rqxesentative  numbers  of 
direat  objects,  plus  the  composition  of  firiendly  faces  with 
which  the  systems  under  test  would  intoact  This  ptper 
explores  the  teal-worid  benefits  and  consid^ations  of 
utUizing  a  D-HWIL  test  tool  fa:  existing  BMD  systems. 
In  additioi,  the  paper  also  gives  considoatiais  for  areas 
where  this  approach  could  yield  more  affordable  BMD 
systems  in  die  future. 


Introduction 

In  order  to  evaluate  BMD  system  effecdveness, 
devdopers  must  achieve  and  demoistrale  measures  of 
performance  by  a  rigorous,  wdl-d^ned  process  involving 
analysis,  simulation,  and  testing  techniques  as  early  in  the 
develrpment  process  as  possible.  These  activities  must 
quantify  aid  characterize  key  technical  parametos  diat 
support  the  system  requirments'  verification  and 
performance  evaluation  process.  An  impolant  part  cl  this 
process  is  the  identification  of  critical  issues  and  shotCalls 
in  system  poformance  early  enough  in  develcpment  to 
allow  for  cost  dfecdve  resolutions  to  occur. 

To  accomplish  these  evaluation  objectives  in  the 
most  efficioit  manner  possible,  many  system  devekpers 
exercise  their  prototype  HWIL  systems  in  conjunction 
with  constructive,  virtual,  and  live  simulations.  These 
prototype  HWIL  systems  sipport  mwe  effective 
performance  assessments  by  using  realistic  batdefield 
configurations  with  rpresentations  of  all  of  die 
components  necessary  for  integrated  system  Test  and 
Evaluation  CT&B).  The  most  cost  effective  approach  to 
devdoping  these  test  tools  is  to  incopoate  previously 
developed  tactical  system  drivers  whoiever  possible. 
Examples  HWIL  systems  using  this  cost  effective 
ipxoach  includes;  the  U.S.  Army’s  PATRIOT  Flight 
Mission  Simulator/Digital  (FMS/D),  die  U.S.  Air  Force 
Theater  Air  Command  &  Control  Simulation  Facility 
(TACCSF),  and  the  U.S.  Navy  AEGIS  Combat  System 
Interface  Stimulator  (ACSIS). 

In  addition  to  individual  system  performance 
assessments,  these  prototype  HWIL  systems  are  suitable 
to  extending  T&E  activities  to  include  integration  and 
interfiice  testing  with  the  various  other  tactical  systems 
within  the  theato  of  operations.  One  of  the  most 
promising  {pproaches  to  accomplish  this  level  of  testing 
is  with  distributed  simulation  technology.  An  excellent 
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example  is  available  with  the  development  of  the  Theater 
Missile  Defense  (TMD)  Family  of  Systems  (FoS). 

The  Ballistic  Missile  Defense  Organization 
(BMDO)  has  directed  the  develc^moent  of  a  TMD  System 
Exociser  (TMDSE)  to  verify  diat  the  TMD  FoS  can 
^ectively  interoperate  under  realistic  batderidd 
condirinns.  These  TMD  systems  will  be  cmnbinarions  of 
existing  inventory,  product  upgrades  and  new  systems  that 
evolve  to  enhance  mission  effectiveness. 

The  U.S.  Army  Program  Executive  OEBce- 
Missile  Defense  (PEO-MD)  is  currently  beginning  the 
third  year  of  develc^ing  the  TMDSE  for  the  BMDO.  The 
TMDSE  is  a  test  tool  that  drives  geographically 
distributed,  real  tactical  system  hardware  and  software  with 
a  common,  synchronized  scenario,  and  evaluates  tbdr 
reipective  interoperability  over  tactical  communication 
data  nets.  The  objective  of  the  TMDSE  is  to  stimulate  the 
track  processing  systems  and  command  and  control 
capabilities  of  the  tactical  equipment  that  will  jKovide  the 
flow  of  infcMination  through  the  tactical  system  interfaces. 
The  stimuli  for  the  track  processing  systems  are  realistic 
reixesentations  of  theater  level  attack  scenarios  with 
d^ensive  actions  and  countoiactims.  The  resulting 
information,  which  flow  through  the  system  interfaces, 
allows  for  the  voification  of  TMD  FoS-level  integration 
and  intoxp^ability. 

D-HWIL  Technology 

F(X  ovCT  7  years  die  Department  of  Defense 
(DoD)  has  been  woridng  to  define  an  inftastmcture  for 
linking  simulations  of  various  types  at  multiple  locations 
to  oeate  realistic,  complex  virtual  environments  for  large- 
scale,  interacdve  exercises.  The  initial  accomplishments 
were  mainly  because  rtf  efforts  by  the  Simulation  Netwok 
(SIMNET)  program  managed  duough  both  the  Advanced 
Research  Projects  Agency  (ARPA)  and  the  U.S.  Army 
Simulation,  Training,  and  Instrumentadon  Command 
(STRICOM).  The  focus  of  these  initial  efforts  was 
mosdy  on  training  applications.  SIMNET  has  evolved 
into  the  Distributed  Intoacdve  Simulations  (DIS) 
technology  that  is  more  flexible  and  robust  and  supports 
diffoent  types  of  simulations  with  different  levels 
fidelity. 

The  DIS  infrastructure  provides  interface 
standards,  communications  architectures,  management 
structures,  fidelity  indices,  technical  ftxums,  and  other 
elements  necessary  to  transftxm  heterogoieous  simulations 
into  unified  seamless  synthetic  ravircNunents.  These 
synthetic  environments  support  a  vdde  range  of  uses  to 
include  design,  prototyping,  test  and  evaluation,  and 


fining.  The  Institute  of  Electrical  and  Electronic 
Engineers  (IEEE)  has  established  Standard  1278  to 
faeiliratp.  commonality  in  the  int^face  between  DIS 
elements.  The  DIS  standards  process  addresses  the 
devdopment  of  architectures,  protocols,  and  message 
ftxmat  to  suiqxxt  DIS  events. 

The  principle  fq)plication  for  DIS  is  still  human- 
in-the-loop  int^action  with  simulations  and  the  synthetic 
enviroiunenL  However,  several  years  ago,  the  concqX 
developed  of  combining  HWIL  with  DIS  technologies  to 
allow  we^xm  system  developers  to  do  eariy  T&E  of  the 
TMD  FoS.  The  application  of  DIS  teclmology  to  D- 
HWIL  testing  rqxesents  many  engineering  challenges 
due  to  requirements  for  voy  high-fidelity  object  state  data, 
timing,  and  data  transmission  rates.  The  TMDSE 
development  uses  DiS  technology;  but,  also  include  some 
other  important  features  discussed  below. 

The  TMDSE  concept  is  to  test  as  much  of  the 
tactical  equipmrat,  to  include  hardware,  software,  and 
tactical  communications  as  is  feasible.  The  TMDSE  tests 
the  tactical  system  configuration  lepresoitative  of  a  task 
force  <q)erating  in  conceit  as  part  of  a  synergistic  TMD 
architecture.  This  approach  provides  the  us^  community 
for  these  drfense  systems  the  dq)th  of  evaluation  in 
system-level  perftxmance  needed  to  insure  mission 
success. 

In  June  ctf  1994,  PEO-MD  demmistrated  that  the 
TMDSE  concq)t  was  obtainable  by  developing  and 
demonstrating  the  Proof-t^-Princ^le  (POP)  configuration. 
The  POP  Demonstration  connected  the  Joint  Tactical 
Ground  Station  (JTAGS)  equiixnent  in  Azusa,  California 
and  the  PATRIOT  Radar  and  Engagement  Control  Station 
(ECS)  in  Bedfod,  Massachusetts  to  the  TMDSE  Test 
Exercise  ControUa-  (TEC)  in  Huntsville,  Alabama.  The 
locations  of  each  of  the  Build  1  particqiants  is  shown  in 
Figure  1.  During  the  POP  Demonstiatirm,  the  TEC 
injected  a  common,  synchronized  scenario  into  these  two 
we^x>n  system  platforms  in  real-time. 

The  TMDSE  Build  1  development  eiqianded  the 
POP  capability  by  adding  additional  weapon  systems  as 
well  as  new  TMDSE  components.  The  new  systems 
included  the  Navy’s  AEGIS  We^X)n  System,  tte  Air 
Force’s  Talon  Shield  and  Control  and  Reporting  Center 
(CRQ,  and  the  Army’s  PATRIOT  ICC  and  BTOC  /  TCS. 
In  aAtirinn,  the  Build  1  enhancements  included  a  more 
robust  dynamic  envmmment  consisting  of  ballistic  missile 
and  air  breather  threats,  intocepttxs,  weatim,  and 
interceptor  and  threat  debris. 
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Figure  1 TMDSE  Build  1  Distributed  Configuration 
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lequiremcM  uoceitjUmy  and  variation. 

Requirements  and  the  implemented 
systems  viability  become  clearer 
and  achieved  at  the  last  Build. 


Build  1  achieves  some  percentage  of  objective 
system  goals.  It  is  constrained  by  funding, 
schedule,  and  tactical  system  availability. 
Some  capabilities  require  time  to  mature. 


Build  I  requirements  and  objectives. 


Figure  2  Evolution  of  Capabilities  to  Achieve  the  TMDSE  Objective  System 


The  TMDSh  development  pniiosopny  is  a 
phased,  incremental  evolutionary  approach.  Each 
developmental  phase  is  a  “Build”.  Currently,  the  PEO- 
MD  is  developing  the  Build  2  configuration.  This 
incremental  development  methodology  embraces  the 
concept  of  “build  a  little,  test  a  little”  to  allow  for 
feedback  from  the  evaluation  of  each  configuration. 
Each  configuration  is  being  evaluated  with  the  TMD 
users  for  a  full  assessment  of  capabilities  and  shortfalls. 
Figure  2  above  illustrates  the  plan  for  the  evolution  of 
TMDSE  system  capabilities  to  meet  the  objective 
system  requirements. 

TMDSE  D-HWIL  Configuration 

Each  of  the  respective  weapon  system  Project 
Offices  mentioned  above  developed  drivers  to  exercise 
or  test  their  tactical  systems  during  the  acquisition 
process.  The  capabilities  within  each  driver  are  unique 
to  the  tactical  system  it  supports.  Shown  in  Figure  3  is 
a  summary  of  the  Build  1  tactical  system 
configurations.  TMDSE’ s  challenge  was  to  combine 
these  drivers  so  that  they  worked  in  unison  to  provide  a 
synchronized,  coordinated,  common,  dynamically 
interactive  environment  to  all  the  tactical  systems 
being  stimulated.  TMDSE  accomplished  this  using  the 
TMDSE  Control  Segment  (TCS)  which  provides  the 
drivers  with  the  threat,  environment,  and  timing  data 
necessary  to  generate  their  respective  simulated  view 
of  the  common  TCS  controlled  environment. 

The  TCS  provides  the  means  by  which  a  test 
operator  can  configure,  execute,  and  summarize  a 
TMDSE  exercise.  Configuration  of  the  TMDSE 
consists  of  generating  data  bases,  building  scenarios, 
establishing  non-tactical  communications  (voice  and 
data),  distributing  data,  querying  the  drivers  for  health 
and  status  and  initializing  all  of  the  drivers.  During  the 
preparation  and  execution  phases,  the  TCS  functions 
include; 

-  configuration  verification 

-  clock  synchronization 

-  sending  object  states  to  the  tactical  drivers 


-  collecting  aaia 

-  receiving  and  distributing  truth  data 

-  dynamic  event  distribution 

-  performing  quick  look  analyses  during  execution 

-  generating  environment  data  (threat  debris,  etc.) 

At  the  same  time  the  tactical  drivers  are  responsible  for 
sending  interceptor  states,  interceptor  debris, 
interceptor  event  status  and  tactical  system  perceived 
data  back  to  the  TCS.  Following  a  test  or 
demonstration,  the  TCS  request  data  collected  by  the 
drivers  in  order  to  combine  and  compare  it  to  TCS  data 
and  tactical  data.  The  TCS  uses  these  data  for  various 
types  of  analyses  supporting  specific  objectives  for 
development,  VV&A,  or  user  evaluation. 

The  tactical  drivers,  although  unique  to  the 
individual  tactical  systems  they  support,  provide  the 
interface  between  the  TCS  and  the  tactical  system. 
These  tactical  drivers  are  responsible  for  generating  the 
"scenes”  based  on  inputs  from  the  TCS,  that  stimulate 
the  tactical  track  processing  systems. 

Physically,  the  TCS  consists  of  the  centrally 
located  Test  Exercise  Controller  (TEC)  and  the  Remote 
Environments  (REs)  collocated  with  each  Tactical 
Driver.  The  TEC  connects  with  each  of  the  REs  using 
High  bandwidth  data  communication  links  (non- 
tactical).  The  REs,  in  turn,  connect  to  the  drivers 
through  a  local  area  network  (Ethernet).  The  driver 
connections  to  the  tactical  systems  are  unique  to  the 
individual  systems.  Each  tactical  system  uses  tactical 
communications  for  coordination  and  execution  of 
tactical  procedures.  The  Build  1  Demo  used  real 
Tactical  Information  Broadcast  System  (TIBS)  and 
Tactical  Related  Applications  Program  (TRAP)  Data 
Distribution  System  (TDDS)  broadcasts,  as  well  as  a 
TADIL-J  communications  emulator  for  joint  tactical 
communications. 
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Figure  3  TMDSE  Buildl  Tactical  Systems 
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Theater  Environment  (TE)  Functions 

The  TE,  located  within  the  TEC,  is  a  real-time 
dynamic  simulation  of  the  physical  environment  (both 
natural  and  man-made)  within  which  the  TMD  Systems 
are  to  operate.  Physical  phenomena  include  threat 
object  propagation,  TMD  Systems  locations  (and 
location  updates  for  mobile  platforms),  propagation  of 
natural  and  man-made  objects,  and  natural  and  hostile 
environments.  The  TE  provides  to  TMD  Systems  only 
that  information  that  the  Systems  would  naturally 
perceive  through  their  sensors  or  which  affects  their 
operational  performance.  By  segregating  simulation 
truth  from  TMD  System  perception,  the  TMDSE 
ensures  that  information  not  be  available  to  the 
Tactical  System  under  the  circumstances  being 
simulated  do  not  bias  the  results  of  integration  tests. 
Each  TMD  System  must  react  to  TE  stimulus  as  that 
System  would  react  in  a  real  world  situation.  The 
threat  and  simulation  scenarios  and  TMDSE 
initialization  data  specifically  configure  the  TE  for 
each  test  or  exercise. 

Test  and  Control  (TO  Functions 

The  TC,  also  located  within  the  TEC,  provides 
the  means  by  which  the  TMDSE  controls  itself  as  well 
as  coordinates  exercise  event  sequencing  and  timing 
with  the  Tactical  Drivers.  In  addition,  the  TC  monitors 
and  records  TMD  System  and  component  performance 
data  and  collects  pre-mission  and  run-time  data. 
Following  completion  of  a  test  run,  the  TC  also 
analyzes  results  and  provides  supporting  data  for  test 
reports.  The  TC  contains  the  TMDSE  TCS  operator 
interfaces,  data  bases,  peripheral  inputs  and  outputs, 
and  instrumentation.  The  TC  starts,  stops,  initializes, 
and  resets  TMDSE  hardware,  software,  and  Driver 
equipment.  For  TMD  systems  equipped  to  process 


external  "test"  commands,  the  TC  will  forward  such 
commands  through  the  Driver.  The  TC  and  other 
TMDSE  functions  also  perform  required  maintenance 
operations. 

TMD  Tactical  Drivers  Functions 

Each  TMD  Program  Office  (namely,  PATRIOT, 
JTAGS,  AEGIS,  CRC,  Talon  Shield)  provides  a  TMD 
Tactical  Driver  through  which  the  TMDSE  Control 
Segment  will  interface  with  their  respective  Tactical 
Systems.  These  drivers  provide  physical  interfaces  to 
the  TMD  Tactical  Systems.  The  drivers  receive 
TMDSE  environments  and  control  messages  from  the 
TMDSE  Control  Segment  functions,  and  convert  this 
data  to  a  format  and  data  rate  that  are  usable  by  the 
tactical  system.  The  drivers  contain  simulations  of 
tactical  components  that  are  missing  or  impractical  (for 
example,  actual  interceptors  and  radar  antennas).  The 
drivers  also  generate  environment  and  scene  data  based 
on  the  TMDSE  Control  Segment  inputs.  Additionally, 
these  drivers  provide  to  the  TCS  data  as  perceived  by 
the  respective  tactical  systems. 

The  communication  networks  consist  of  a 
combination  of  local  and  wide  area  networks.  These 
different  networks  interconnect  the  various  TCS 
components,  TMD  Tactical  Drivers,  TMD  Tactical 
Systems,  and  Tactical  (or  emulated  tactical) 
Communication  Networks  (TCN).  The  communication 
networks  are  of  two  types:  those  that  address  the  test 
control  functionality  and  those  that  provide  the  tactical 
networks  for  the  systems  under  test.  Figure  4  provides 
an  illustration  of  the  Build  1  hardware  configurations 
and  their  interconnections. 

The  TMDSE  test  control  networks  are  high 
bandwidth  (that  is,  T1  link)  encrypted  lines  that  join 
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the  TEC  in  Huntsville  at  Teledyne  Brown  Engineering 
with  all  Remote  Environments  at  each  Tactical  Driver 
site.  Local  Area  Networks  connect  the  Remote 
Environments  to  the  Tactical  Drivers.  The  network 
connections  from  the  Tactical  Drivers  to  the  Tactical 
Systems  built  to  be  compatible  with  the  Tactical 
Systems  that  they  support. 


systems  emulating  a  Joint  Tactical  Information 
Distribution  System  (JTIDS).  In  addition,  the  simulated 
threat  ‘injected’  into  the  JTAGS/Talon  Shield  systems 
generated  real  TIBS  -  TDDS  cueing  messages  received 
by  the  PATRIOT,  AEGIS,  and  CRC  elements.  The 
transmission  of  these  TIBS  and  TDDS  messages  are  by 
either  live  satellite  broadcast,  land  line  emulator,  or  a 
combination  of  the  two. 


The  TCN  connects  the  tactical  systems  to  each 
other.  These  interfaces  are  the  same  communications 
expected  of  the  TMD  components  with  regard  to 
protocol,  message  formatting,  and  routing  selection. 
Figure  5  illustrates  the  Build  1  tactical  communication 
links.  In  future  builds,  the  interfaces  to  the  TCN  will 
include  the  TCS  to  actively  monitor  and  stimulate 
activity  on  and  through  the  network.  For  Build  1,  the 
TCS  passively  monitors  and  displays  tactical 
communication  traffic  using  the  U.S.  Naval  Command, 
Control,  and  Ocean  Surveillance  Center’s  (NCCOSC) 
Link  16  Emulator  and  Communications  Monitor  (the 
NRaD  Gateway). 

The  NRaD  Gateway  provides  the  tactical 
communication  link  between  the  individual  weapon 


TMDSE  Application  of  PIS  Protocols 

The  TMDSE  Build  1  design  includes  the 
application  of  DIS  protocol  data  units  (PDUs)  used 
between  the  Test  Exercise  Controller,  the  Remote 
Environments,  and  the  individual  tactical  drivers.  In 
addition,  the  TMDSE  Build  1  configuration  is  a  DIS- 
compatible  test  tool  incorporating  twelve  (12)  different 
PDUs  listed  in  the  Institute  for  Simulation  and 
Training’s  (1ST)  ‘"Standard  for  DIS  -  Application 
Protocols”  Version  2.0,  Fourth  Draft  (2.04).  These  12 
PDUs  are:  Entity  State  PDU,  Acknowledge  PDU,  Fire 
PDU,  Action  Request  PDU,  Detonation  PDU,  Action 
Response  PDU,  Create  Entity  PDU,  Data  Query  PDU, 
Start/Resume  PDU,  Stop/Freeze  PDU,  Data  PDU,  and 
Set  Data  PDU. 


Figure  5  TMDSE  Build  1  Tactical  Communication  Links 
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TMDSE  Computer  Hardware  Configuration 

The  TMDSE  execution  environment  is  a 
heterogeneous  configuration  of  workstations  and 
associated  operating  systems.  Sun  Microsystems 
workstations  running  the  Solaris  2.4  operating  system 
accomplish  the  real-time  aspect  of  the  TCS.  TMDSE 
graphic  processing  is  primarily  on  Silicon  Workstations 
running  IRIX. 

The  Sun  platforms  are  SparcStation  20s,  Ultra 
Sparc’s,  and  SparcServer  1000s.  These  are 
multiprocessing  architectures  with  up  to  four  processors 
on  the  SparcStation  20s  and  up  to  eight  processors  on 
the  SparcStation  1000s.  Each  platform  includes  a  GPS 
card  for  performing  precise  time  synchronization  among 
the  widely  distributed  nodes.  Ethernet  interfaces  handle 
communication  between  platform  nodes  with  many 
platforms  containing  multiple  Ethernet  interfaces  to 
support  the  TMDSE  configuration. 

The  operating  system  installed  on  the  Sun 
workstations  is  Solaris  2.4,  a  Sun  version  of  UNIX. 
Solaris  supports  symmetric  multiprocessing  allowing 
programs  to  execute  concurrently  on  several  processors 
transparently.  Solaris  also  includes  POSIX  compliant 
real-time  extensions.  These  real-time  extensions  allow 
real-time,  preemptive,  time  dependent  applications 
such  as  the  TMDSE  to  be  effectively  implemented  on 
the  Sun  workstation  environment. 

The  software  for  TMDSE  is  being  primarily 
developed  in  Ada  on  Sun  workstations.  Current  Source 
Lines  of  Code  (SLOCs)  estimates  for  the  final  Build  3 
configuration  of  the  TCS  is  around  200K  lines.  90%  of 


this  code  will  be  in  Ada  and  10%  written  in  C.  The  Ada 
being  used  is  the  Sun  IMPACT  Ada.  This  Ada  is  a 
multi-threaded  compiler  that  allows  multitasking  Ada 
programs  to  run  on  multiple  processors  in  a  truly 
concurrent  manner.  The  Ada  environment  has  a  rich  set 
of  GUI  tools  that  greatly  enhance  developer’s 
productivity. 

The  TMDSE  2-D  map  displays  as  well  as  Test 
and  Control  displays  execute  on  the  Sun  workstations 
using  both  monitors  and  x-terminals.  All  display 
software  run  on  Sun  workstations  is  in  Ada.  The  Silicon 
Graphics  workstations  are  primarily  for  high  resolution 
3-D  graphics  displays.  Display  software  run  on  Silicon 
Graphics  workstations  is  in  both  Ada  and  C  where 
required.  Both  2-D  and  3-D  displays  are  X- Window 
Motif  based  graphics. 

D-HWIL  Benefits 

Identification  of  issues  and  shortfalls  in  system 
performance  early  in  development  process  is  critical  so 
that  resolution  is  more  cost  effective.  Figure  6  provides 
a  graphic  illustration  of  this  benefit.  D-HWIL  testing 
allows  developers  to  evaluate  what  effects  an 
operationally  realistic  environment  has  on  early 
prototypes  of  developmental  systems.  It  provides  a 
robust  test  environment  with  representative  numbers  of 
threat  vehicles  and  equipment,  plus  the  suite  of  friendly 
C4I  and  weapon  systems  with  which  a  system  under 
test  would  interact.  These  early  assessments  allow  for 
more  complete  testing  during  development  including 
environments  that  are  not  feasible  in  field  tests.  In 
addition,  D-HWIL  enhances  test  planning  by  helping  to 
determine  which  range  tests  are  the  most  critical  and 
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thereby  allowing  the  program  to  conserve  scarce  test 
resources. 

Establishing  standardized  interface 
applications  during  initial  development  reduces  cost. 
This  approach  allows  early  interoperability  testing  using 
HWIL  simulators  linked  with  the  other  players 
representative  of  the  intended  theater  of  operations. 
This  realistic  loading  on  equipment  and  personnel 
achieved  using  D-HWIL  is  necessary  to  accurately 
assess  the  tactical  system’s  capabilities  in  the  field. 
This  also  allows  the  early  evaluation  of  tactical 
operator  interactions  as  well  as  opportunities  for 
extensive  training  over  a  wide  range  of  operational 
scenarios. 

One  of  the  other  major  benefits  in  combining 
both  HWIL  and  real  time  system-level  simulations  is 
developing  confidence  in  the  representative  models  and 
simulations  (M&S).  These  M&S  are  critical  to  the 
TMD  FoS  acquisition  process  since  they  must  generate 
the  bulk  of  the  performance  data  used  by  the  evaluators. 
Previous  experience  has  shown  the  importance  of 
planning  and  executing  verification,  validation,  and 
accreditation  (VV&A)  activities  as  early  as  possible  for 
each  major  system.  A  successful  VV&A  program  for 
BMD  systems  requires  that  all  of  T&E  activities  build  a 
consistent  and  synergistic  evaluation  data  base.  To 
accomplish  this  objective,  it  is  vital  that  all  T&E 
activities  have  the  structure  and  compatibility  in  terms 
of  test  scenarios,  environmental  conditions,  and 
operational  concepts  afforded  by  using  D-HWIL. 
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